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Separation Logic is a non-classical logic used to verify pointer- intensive code. In this paper, however, 
we show that Separation Logic, along with its natural extensions, can also be used as a specification 
language for concurrent-system design. To do so, we express the behavior of three very different con- 
current systems: a Subway, a Stopwatch, and a 2 x 2 Switch. The Subway is originally implemented 
in LUSTRE, the Stopwatch in Esterel, and the 2x2 Switch in Bluespec. 



1 Introduction 

Concurrent systems, specified today, can have very different properties. Depending on these properties, 
a practical specification language is chosen. For instance, consider a designer who can choose between 
the synchronous language Esterel and the guarded-command language Bluespec in order to specify 
the modal behavior of a Stopwatch, on the one hand, and the shared-memory behavior of a 2 x 2 Switch, 
on the other hand. The designer will typically choose Esterel for the Stopwatch and Bluespec for the 
2x2 Switch and not the other way around. In other words, while it is of course theoretically possible to 
express modal behavior with Bluespec and shared-memory behavior with Esterel, it is -in terms of 
practical expressiveness- not interesting to do so. 

The statements in the previous paragraph are based on "common design experience", not on a formal 
metric of practical expressiveness. To the best of our knowledge, such a metric is not available in the 
current literatur43- In this paper we do not try to find such a metric either, for we believe it is wiser to 
first obtain many specifications of various systems using different specification languages and to compare 
them based on intuitive notions of "practical expressiveness". Based on these informal comparisons, we 
can then search for a metric that is both well defined and practically relevant. 

In this paper we choose the formalism of Separation Logic and its natural extensions to express the 
behavior of three very different systems: 

• A Subway system, originally specified with LUSTRE [81. 

• A Stopwatch, originally specified with Esterel Q. 

• A 2x2 Switch, originally specified with Bluespec IH. 

'Note that the conciseness of a specification is too simplistic a metric: a lengthy specification Sq can be preferred over a 
short specification 5i if, for instance, 5o explicitly captures a design requirement that is only implicitly present in 5i . 
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Figure 1: A scenario of the Subway system 



Our specifications are based on an analogy that we make with photography, explained below. The anal- 
ogy is formalized by means of Separation Logic |[T3llT5l . This logic, in turn, is an extension of Hoare 
Logic and is typically not used in the way we use it in this paper, i.e. as a specification language. 

An Analogy with Photography 

Given a concurrent system such as the Subway system in Figure [TJ we make the following analogy 
with photography. Let various photographers be assigned to different locations in Figure [T] By taking 
consecutive camera snapshots, each photographer captures local change of some part of the Subway. 
Then, by combining all local changes, we obtain a complete specification of the Subway. 

For instance, suppose photographer Phi is assigned to take snapshots of track A in Figure [U while 
photographer Ph2 is assigned to track B. Phi can, by taking one snapshot, either observe the presence 
of a train on track A, denoted by 1@A, or the vacancy of track A, denoted by 0@A. By taking two 
consecutive snapshots. Phi can observe four possible changes: (a@A, b@A) with a,b ^ {0, 1} -where 
we shall use (a, b)@A to abbreviate {a@A, b@A). For example. Phi may observe the arrival of a train 
on A, denoted by (0, 1)@A. Likewise, Ph2 may observe the continuous vacancy of track B, denoted by 
(0,0) @B. By combining the observations of Phi and Ph2, we obtain the composite change (0, 1)@A * 
(0,0) @B, describing a system in which a train arrives on A while, simultaneously, track B is vacant. 

The example, presented above, can be extended by adding more photographers, as we shall illustrate 
in Section [2] when discussing the Subway in more detail. In addition, we can generalize the notions 
of 'snapshot' and 'change' to the notion of 'change of change'. This extension will be needed when 
specifying the modal behavior of a Stopwatch in Section [3l In terms of the analogy, the photographer 
capturing a scene by means of 'change', has become a camera man, capturing the change from one scene 
to another. Another generalization is needed when specifying the 2x2 Switch in Section |4] There, the 
concept of 'snapshot' is generalized to that of an 'hierarchical snapshot', implying that each photographer 
can zoom in on specific details of the concurrent system under investigation. Consequently, hierarchical 
change is used (instead of plain change) to capture the concurrent behavior of the Switch. 

Related Work 

Our analogy with photography is formalized in this paper by using the following embarrassingly simple 
logics. First, the Logic of Snapshots is merely an instance of Separation Logic's assertion language using 
the @ primitive of Ahmed et al. [1] instead of the usual points-to predicate |[T3l[T5l . The key point is that 
formulae denote unary predicates over snapshots (shot) of the system state. The second logic is ChaLo, 
the Logic of Change. It is basically Yang's "Relational Separation Logic" |16| where formulae denote 
binary relations cha of the form {shotin , shotout ) rather than unary predicates. For notational convenience 
we let {fst cha) refer to shotin and (sndcha) to shotout- The third logic is Cha^Lo where formulae denote 
relations on relations over snapshots, i.e. sets of elements of the form: {chain, chagut)- But the semantics 
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will require that {snd chain) and {fstchaout) are always equal (or else completely irrelevant), so formulae 
actually denote triples of snapshots. Hence, Cha^Lo is a straightforward adaptation of ChaLo from binary 
to ternary relations. Continuing in the same manner, we then present Cha^Lo, denoting elements of the 
form: {{chaijchaj) , {chaT,,cha^)) where {sndcha2) is equal to (fstchaj,). Further extrapolation results 
in Cha^Lo and, in general, in Cha"Lo with n = 2*^ and k a strictly positive integer. In summary, it is more 
the use of the logical definitions that is new and interesting, rather than the definitions themselves. 

The formalism in this paper abides by the Synchronous Hypothesis |l3l[T4l. To illustrate this, consider 
(0, 1) @A * {G,R) @La, which can be read operationally as follows: "When track A's sensor senses the 
arrival of a train, the Subway system responds by turning traffic light La from green (G) to red (/?)." 
Operationally, it makes no sense to reason in the opposite direction; i.e. by starting with the light and 
concluding with A's sensor. Thus, we have an ordering from (0,1) @A to {G,R) @La. But, since * 
requires that both occur simultaneously, {G,R) @La has to be an instantaneous reaction to (0, 1) @A. 

The analogy with photography, resulting in the concepts of 'snapshot', 'change', and 'change of 
change', sets it apart from other well-established formalisms, such as Statecharts f9l. Communicating 
Sequential Processes 1, 101 . the tt -calculus [12], spatial logics (e.g. [4]), and process algebras [6], just to 
name a few. Lack of space prevents us from delving into these other formalisms here. 

2 Subway 

We introduce the Logic of Snapshots and its extension ChaLo (i.e. the Logic of Change) to specify a Sub- 
way. The Logic of Snapshots is system dependent. That is, we shall introduce syntax for snapshots that 
depends on the Subway. Later, when discussing the Stopwatch (Section (3]) and the Switch (Section |4]), 
we shall introduce other syntax. ChaLo, on the other hand, is only defined once. 

This section consists of three parts. Section [2?T] presents the design intent of the Subway. Section l2!2l 
illustrates how the Logic of Snapshots and ChaLo can be used to specify the Subway. Finally, Section 123] 
presents the formalization. 

2.1 Design Intent 

The objective in Figure [T] is to design a Subway system so that a train can enter by track A, temporarily 
use track B, and then leave by track C |8|. At all times, at most one train is present in the Subway 
system. Seven state elements constitute the system. Four state elements are inputs: the sensor values of 
the tracks A, B, and C, and the switch S. Three state elements are outputs: the actuator of the switch S 
and the two traffic lights La and Lb. Each state element is presented below along with its possible values: 

(i) sensors of A, B, and C 1 

(ii) Sen_S, Act_S AB off BC 

(iii) La, Lb G R 

When a train is on a track (e.g. track B in Figure [T]), then the corresponding sensor value is 1, else it is 
0. The sensor of switch S has the value AB when tracks A and B are connected and BC when tracks B 
and C are connected. The value off occurs when no tracks are connected, as is the case in Figure [T] The 
actuator of switch S has the value AB when the switch is being steered in order to (eventually) connect 
tracks A and B. Similarly, the value is BC when connecting tracks B and C, as illustrated in Figure [T]by 
the arrowed arc. The actuator has the value off when the switch is not being steered (i.e. typically when 
two tracks are connected). Traffic lights can either be green (G) or red (/?). Green light La allows a train 
to enter track A from the left. Green light Lb allows a train to depart from track B by moving backwards 
(preferably onto track C!). 
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2.2 Some Specifications 

We now illustrate the Logic of Snapshots and ChaLo by presenting some specifications of the Subway. 
Since the complete formalization of the Logic of Snapshots is straightforward but lengthy, we merely 
illustrate it below. The more important logic ChaLo, on the other hand, is illustrated below and formally 
defined in Section [231 

As a first example, consider the following snapshot specification in the Logic of Snapshots: 

(1) 0@A * 1 @B * G@Lb * BC@SenS 

It partially describes a particular instance of the Subway: track A is vacant, track B is occupied, traffic 
light Lb is green (G) and hence granting exit to the train on track B. The switch S is, based on its sensor 
(SenS), connecting track B with track C. The snapshot is partial because it does not capture the status of 
track C, the traffic light La, and the actuator of the switch S. 
Expression (1) is a syntactic abbreviation for: 

(2) < 0@A * 1 @B, BC@SenS, emp, G@Lb > 

which is a tuple of four snapshot expressions. The first entry 0@A * l@B describes the states of the 
tracks, the second describes the switch's sensor, the third describes the switch's actuator, where emp 
abbreviates "empty", and the fourth describes the traffic lights. The meaning of (2) is described next. 

Let Tr = {false, true} denote the set of truth values, Var a set of variables, and Val a set of values: 
Val = {0, 1 } U {AB, BC, off} U {R, G} and Va/^ = ValU{±}. The set of assignment functions is Asgmt 
:= Var Val±. Let s denote an assignment function, i.e. s € Asgmt. Then, the semantical interpretation 
of (2), using s, results in a semantic snapshot {shoti , shot2, shotj, shot^^): 



(3) s, {shot\, shot2, shot^, shot/^) 

(4) ^ < 0@A * 1 @B, BC@SenS, emp, G@Lb > 

(5) iff s,shoti \= 0@A*l@B and 

(6) s, shot2 ^ BC@SenS and 

(7) s, shot^ \= emp and 

(8) s,shot4 \= G@Lb 



That is, each local semantic snapshot shotj with / G {1,2,3,4} models the corresponding syntactic snap- 
shot as a function. Le., shot^ is a function that maps A to 0, B to 1, and C to _L. Function shot2 maps SenS 
to BC. Function shoti, maps AcfS' to _L, since no information ("empty" emp) is present about the actuator 
Acts. Function shot a, maps La to _L and Lb to G. Finally, we remark that {shot\, shot2, shots, shot a,) € 
Snshot where Snshot is the domain of semantic snapshots. 

As a second example, we illustrate the difference between Separation Logic's spatial conjunction * 
and classical conjunction A. Let us take (5) and replace * by A, then we have: 

(9) s,shoti ^ 0@AA1@B 

(10) iff s, shoti 0@A and 

(11) s, shoti N 1@5 

Now, (10) states that shoti is a function mapping A to and B and C to _L. On the other hand, (11) states 
that shoti maps S to 1 and A and C to _L. This is clearly not possible, so A is used incorrectly in (9). 

The previous example shows that A can not replace * without altering the intended meaning. This is 
due to the chosen semantics of @: 0@A only describes the state of track A. In the alternative classical 
semantics, 0@A would describe the complete state of all three tracks in the Subway system, with the 
additional knowledge that track A is vacano The same arguments also hold for change, such as (0, 1) @A. 



It is of course possible to avoid the use of * in this paper by redefining the meaning of @ in accordance to the classical 
semantics, but the purpose of this paper is to use Separation Logic for case studies, such as the Subway system, for which it 
was not initially intended. 
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For a third example, recall the photographers Phi and Ph2 from Section[T] When both photographers 
combine their observations, they conclude that, in accordance to a correctly-behaving Subway system, 
the following implication has to hold: (0, 1) @A —>■ (0,0) @B. In words: if a train arrives on track A, 
then, at the same time, track B remains vacant. That is, it is impossible for Phi to observe (0, 1) @A 
while Ph2 observes, say, (1,0) @B. 

The implication (0, 1) @A —>■ (0,0) @B is an abbreviation for: 
{0,\)@A*3x3y{x,y)@B =^ 3/3/ (x',y)@A * (0,0) @S, 

where we have ensured that the same state elements (A and B) are present on the left- and righthand side 
of That is, — > is defined here (by example) in terms of =^, which, in turn, is defined formally in the 
next section (cf. Table [T]). 

As a fourth and final example, consider (0, 1)@A ^ {G,R) @La, which is an abbreviation for 
[(0, 1) @A ^ {G,R) @La\ a [{G,R) @La ^ (0, 1) @A]. It describes the arrival of a train on A while 
traffic light La turns from green to red. Using this. Phi, Ph2, and the photographer of light La can com- 
bine ((g)) their observations as follows: 

(12) [(0,1)@A^ (0,0)@B] (g) [{0,1) @A ^ {G,R)@La] 
From this we can, for instance, deduce that {G,R) @La implies (0,0) @B. 

Similar to * and the use of ® aids us in obtaining a short formal exposition. It could be completely 
avoided by only using * and A but at the cost of longer specifications. It too is formally defined in Table[T] 

Additional Notation 

Let Xj^:=Xyj {-L}. For / :: Aj^ — > we write / = X_x. a to denote the mapping: /(-L) = -L and 
f{a) = [a/x] a for a e A. Also, the domain {domf) of a partial function / is the set of x's such that / (x) 
does not equal _L. In particular, {dom (Ax._L)) = 0. Finally, for domains D and E, let [D E] denote the 
set {f \ f :: D E}. Consider functions f,g ^ [D —>■ E±\. We define the operations ft and . as follows: 

tJ :: {D^E^)^^iD^E^)^^Tr^_ 

tJ := {domf) r\ {doing) ==^ 

. :: {D^E^)^^{D^E^)^^{D^E^)^ 

■ := A/.A^.if/Hgthen/Ugelse± 
For example, if we revisit the partial function shot\ in (5). Then shot\ = shot" . shot\ where shof^ is a 
function that maps A to and B and C to _L. Likewise, shot\ maps B to 1 and A and C to _L. Clearly, 
shot'^ and shot\ have disjoint domains: shot" jj shot\. 

2.3 Logic of Change 

We are now in a position to present ChaLo, the Logic of Change. After taking the following four remarks 
into account, Table[I]can be consulted. 

First, we define semantical change as a pair of semantical snapshots: 
ch € Change := Sishot x Sishot 
Second, given semantical changes chi and c/j2, the disjointness (jj) and the combination (.) of chi and 
c/i2 can be defined: 

chi,ch2 e Change 

chi ~ {shoti, shot'^) 

ch2 = {shot2, shot'-^^ 

c/?iftc/i2 iff shot\'^shot2 and shot['^shot2 

chi.ch2 := {shot\ .shot2, shot'-^.shot'2j 
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(1) P,Q ::= ExprRel \ (Snap, Snap) \ false \ P;Q | 
(2) 

Sugar: 
(3) 



P^Q \ P*Q \ P(!^Q \ 3x.P 
(Expri^Expri) @ Place 



(Expri @Place, Expri @Place) 

(4) ^P = P^ false 

(5) true = ^false 

(6) PVQ = hP)^Q 

(7) PhQ = -(-PV-e) 

(8) V.v.P = -^3x.^P 

(9) Vx.y.P = MxMy.P 
Semantics: 

(10) s,ch ^ ExprRel 

iff (lExprRell s) 

(11) s,{shotj„,shoto,„) ^ {Snapj„,Siap„„,) 

iff 

s, shotiii 1= Snapin and s, shotout \= Siwpo, 

(12) s,ch \= false never 

(13) i, (shoti„,shot,„) ^ P;Q 

iff 

3shot„„p G Snshot. 

s, (shotin, shot„np) |= P and 

i, {shot,„p,shotout) h 2 



(14) eft h -P^G 

iff 

if i, eft ^ P then .v, ch \= Q 

(15) i, {shotin,shot„„i) h -P* 2 

iff 

3shotj^, shotf^^ £ Snshot. 

shotj^ tt ™d 
i/iof,,, = iftof;), . i/iof,? and 

3«ftof^„,, shot^^j G Snshot. 

shot^^„ishotl„ and 
iftofou, = . ifto(,^„, and 

i, ishotlj, shotl^g^ 1= P and 

i, (*fto?2,iftof2„) 1= Q 

(16) s, eft ^ P«)e 

iff 

Bcfto, cfti , cft2 G Change, 
s, cho .ch[ 1= P and 
i, cfto . cfti 1= 2 and 
ch\^ch2 and 
eft = cfto .eft 1 .cft2 

(17) i, eft ^ 3x.P 

iff 

3v G Vo/. * [a- v] , eft ^ P 



Third, the semantics of a ChaLo formula P is of the form: 

s, [shot in, shot out) \= P or s, ch |= P 
with .s e Asgmt 

shoti„ , shot out £ Snshot 

ch = [shotin , shotout ) 
free (P) C [dom s) 

where free (P) denotes the free variables in P. Fourth, an example of an expression relation ExprRel is 
x = I and its valuation (lExprRelJ s) amounts to checking whether (sx) = 1 holds. The trivial definition 
of lExprRel} is omitted from this paper. 



3 Stopwatch 

Our second case study is a Stopwatch, introduced in Section 13.11 To capture its behavior, we shall 
introduce the Logic of Change of Change (Cha^Lo) and similar extensions (Cha'^Lo, Cha^Lo, . . .) in 
Section |3^ Finally, various specifications of the Stopwatch's behavior are presented in Section 1331 
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Figure 2: (i) The Stopwatch, (ii) the Cha^Lo diagram for cha^^^^^, and (iii) the Cha^Lo diagram for 



3.1 Design Intent 

The design intent of the Stopwatch is too lengthy to present in plain English. Therefore, we let our 
specifications speak for themselves. They can also be checked against the original Est ere 1 specification, 
presented in |7 |. 

The Stopwatch in Figure I2i) can be briefly described as follows. The input signals START_STOP (or 
STRP for short), TICK, and RESET are immutable elements. That is, their value is completely determined 
by the external behavior of the Stopwatch. In fact, STRP and RESET are buttons which are pressed (1) 
or depressed (0) by the user, and TICK is the signal (0 or 1) of an external clock. The internal register 
COUNTER and the output signal TIME are mutable elements. That is, their value is determined by the 
internal behavior of Stopwatch. Finally, we also use an internal register MODE, not shown in Figure |2] to 
book-keep the current mode of execution. It too is a mutable element. 

The locations, presented above, can be assigned to the photographers. We present six examples. First, 
(0, 1) @strp, describing change from 0@strp to 1 @strp, captures the behavior of a user who presses the 
STRP button. Second, (0,1) @strp * (0,1) @reset describes a user who simultaneously presses both 
the STRP and RESET buttons. Third, {x,x+ \)@time expresses an increase of TIME from x to x+l. 
Fourth, {x,abs)@time expresses the sending of x to TIME, followed by not sending anything to TIME 
(i.e. an "absent" signal). In general, {a,b)@time is syntactically correct when a,b ^ NU{abs}. Fifth, 
(0, l)@tick describes a positive TICK. In general, {a,b)@tick is syntactically correct when a,b ^ {0, 1}. 
Sixth, {init ,stop)@mode expresses that the system changes from mode init to mode stop. In general, 
{a,b)@mode is correct when a,b ^ {init, stop, start}; its intended meaning will become clear later. 

3.2 Logic of Change of Change and Beyond 

The Stopwatch is a prime example of modal behaviour: pressing a button of the Stopwatch can have a 
different effect, depending on the mode of operation. While the other two case studies in this paper only 
contain one mode of operation, the Stopwatch contains several: chainu, chastop, chastart, cha^^^j^, cha'^^^^f, 
. . . We present some intuition about these modes, before defining the Logic of Change of Change (i.e. 
Cha^Lo) and its extensions. The meaning of each mode will become apparent in Section [331 

The modes chaMt, chastop, and chastart are expressed as simple ChaLo formulae. Mode cha\^^^-^, on 
the other hand, is expressed in Cha^Lo, describing transformations between modes chamu, chastop, and 
chastart- That is, chal^^^j^ describes an hierarchical mode, containing the simpler modes cha^t, chastop, 
and chastart, as is illustrated graphically in Figure Oil). Formula cha^^^^t expressed in Cha'^Lo and 
describes transformations between Cha^Lo formulae. That is, chajgset describes an hierarchical mode, 
containing simpler modes (e.g. cha^^^^^), as is graphically illustrated in Figure Hfiii). This hierarchi- 
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Table 2: 


Cha^Lo 




(1) U, V :■= ExprRel \ [P, Q) \ false \ U'V \ 


(13) 


i, (chi„,chou,) ^ U 


(2) U \ U *V \ U (g>V \ 3x.U 




iff 


(3) where P and Q are ChaLo formulae. 




if s, (chi„,cho„,) ^ {/ 


Sugar: 




then .V, (chi„,cho„,) ^ V 


(4) {{a,b),{c,d))@p = {(a.b)@p,{c,d)@p) 


(14) 


i, (chi„,chou,) ^ U *V 


(5) = false 




iff 

3c/!-„ , chj^ e Change. 


Notation: 




chlichl and 


(6) If ch = (shotin, shotout) 




c/i,„ = c/if^ . c/i? and 


(7) then (fstch) = shoti„ 




^chl^nchl,,, <^ Change. 


(8) and (sndch) = shotoui 




chLttchlu, and 


Semantics: 




c/!m,f = chl„ ■ chi,, and 


(9) s, (chi„,chaut) \= ExprRel 




s, {chl,chl,„,) ^ U and 


iff (lExprRelj s) 




^> {chi,chl,) h V 


(10) s,(ch,„,ch„„,) ^ (P,Q) 


(15) 


i, (chj„,chout) ®V 


iff 




iff 


s, chji, 1= P and 




3c/!^^, c/i/„, c/!^„ e Change. 


s, ch„ut h Q and 




chi„=ch%.chl.chl and 


(sndchj„) = (fstchout) 






(11) s, (chi„,chout) H never 




c/!o„, = c/i!;„, . chl„ . chl„, and 


(12) .V, (c/!,-„,c/i„„,) h 




s, {ch°^ . chl , ch°„, . chl^, ) |= {/ and 


iff 




s, (cA0.c/i2„,ce,.cO hV 


3ch„„p e Change. 


(16) 


s, (chi„,chou,) h 3-v.f/ 


s, (chi„,ch,„p) 1= C/ and 




iff 


i, (ch,„p,chou,) h ^ 




3i' e W//. .s [x v] , (chi„,choM) h 



cal extrapolation continues with Cha^Lo formula cha^^^, describing transformations between Cha'^Lo 
formulae. In general, we deal with a Cha'^Lo formula with n = 2*^ where k is strictly positive. 

A Cha^Lo formula U is semantically interpreted as a pair of changes: 
s, {chin,chout) \= U with: s ^ Asgmt and free{U) C [doms) and 

chin,chout G Change := ^shot x Sishot 
The pair {chin, chant), called a transformation, denotes the change of c/z,„ into chout- The definition of 
Cha^Lo in Table[2]is self explanatory; we stress the similarity with ChaLo in Table[T] 

Continuing in the same manner, a Cha^Lo formula, such as {U, V), is semantically interpreted as a 
pair of a pair of changes: 

S,i{chuch2),ich3,ch4)) h iU,V) 

iff 

s,{chi,ch2) \= U and s,{ch^,ch4) \= V and {snd chj) = {fst ch^) 
where U and V are Cha^Lo formulae. Cha^Lo's complete definition is obvious and omitted from this 
paper. The same remark holds for Cha^Lo (a pair of a pair of a pair of changes) or, in general, Cha"Lo 
with n = 2*^ where k is strictly positive. The logics Cha^Lo and Cha^Lo are used in Section [33] to capture 
the preemption mechanisms of the Stopwatch. 
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Conventions 

We present two conventions. First, an underscore denotes a don't care value. E.g., counter 
abbreviates 3x{x,0)@ counter. Likewise, (_,_)@coM?ifer abbreviates 3x3y{x,y)@ counter. 

Second, similar to Section l2!2l the implication (0, 1) @strp (0,0) @reset abbreviates: 
(0, 1) @strp * (_,_) @reset =^ (_,_) @strp * (0,0) @reset. 

The previous remark holds for any of the logics. Consider for instance Cha^Lo and the following 
expression: 

start ; ^^^stop ) 

and suppose chustop and cha^tart only describe changes of TICK, COUNTER, and TIME. Then this expres- 
sion is an abbreviation for: 

( (0, 1) , (_, _) ) @strp * ( (_, _) , (_, _) ) @tick * 
( (_, _) , (_, _) ) ©counter * ( (_, _) , (_, _) ) @time 

( (_,_) , (_,_) ) @strp * [{chastop,cha,tart) V {chastart,cha,top)] 



3.3 Some Specifications 

We start by specifying the behavior of a Basic Stopwatch, which is similar to the Stopwatch in FigureOi) 
except that the RESET button is excluded. The Basic Stopwatch's behavior is visualized by the Cha^Lo 
diagram in Figure |2tii). The diagram distinguishes between three modes of operation: chaMt, chustop, 
and chostart- After an initialization phase, corresponding to chajnn, the system enters a loop, executing 
either mode cha^top or chastart, depending on the user's input. That is, by pressing STRP, the Basic 
Stopwatch transitions from mode chastop to cha^tart or vice versa. This is expressed in Figure [JJ^ii) by 
the label (0, 1) @strp. On the other hand, if STRP is not pressed, the Basic Stopwatch stays in its current 
mode (i.e. chastop or chustart)- 

The three modes are clarified as follows. First, mode chainu amounts to setting COUNTER to the value 
0. That is: 

chainit '■= {init,_) @mode * (-,0) @counter 

Note also that mode book-keeps the current mode, which in this case is init. Second, 

(1) chdfjtop ■ — ^^^stop ' ^^^stop " 

The first change chaf/J'j, expresses that the value of the COUNTER stays the same and it's value x has to be 
emitted to TIME: 

chal!^gp := (stop,-) @mode * 3x. [(x,x) @counter * (_,x) @time] 

Since the value x only has to be emitted once, cha^^'p is immediately followed in (1) by cha"tl"p , which 

expresses that an absent signal abs is sent to TIME: 

cha'^fp := {stop,S) @mode * 3x. [{x,x) ©counter * {_,abs) @time] 

Third, 

(2) cha^tart '■— (^f^^start ^'-^'^'start- 

The first conjunct cha\^^^ expresses that, at every positive TICK, the value of COUNTER is incremented by 
one (from x—\tox) and sent to TIME: 
chalf^^t := {start, _) @mode * (0, 1) @tick* 

3x. [(x— l,x) @counter * (_,x) @time] 
The second conjunct in (2) states that, in the absence of a positive TICK, the value of COUNTER remains 
constant and an absent signal is sent as output: 
cha^art '■= {start,.) @mode * [(0,0) @tick V (1,_) @tick] * 
3x. {x,x) @counter * {_,abs) @time 
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Having defined the ChaLo formulae, we now define the Cha^Lo formulae of Figure |2tii) in three 
steps. First, transformation transfi expresses the unconditional transition from chatnit to chastop'- 
transfi := {chainu * {-,-)@time, chagfop) * 

{{.,.),{.,.))@strp *{{.,.), {.,.))@tick 
That is, after the initialization phase (i.e. chainit) has taken place, we automatically end up in chastop- 
Second, transf2 expresses that when pressing button STRP, a transition can take place from chastop to 
chustart or vicB versa: 
transf2 := Ia Atg 
with: 

tA {istop,.),{_,_))@mode * ( (0, 1) ,(.,.)) @.9fr/7 

{chastop * (-, -) @tick, chostart) 
tB := {{start, _),{.,_))@mode * ( (0, 1) ,(.,.)) @ifr/7 

{chastart, chastop * (-, -) @tick) 
Third, transfs expresses that when button STRP is not pressed, the current mode stays the same: 
transfi := tc Ato 
with: 

tc := {{stop,.),{.,.))@mode * -( (0, 1) ,(.,.)) @rfrp 

{chastop * (-, -) @tick, chastop * (-, -) @tick) 
to := {{start,.) ,{_,_)) @mode * ~ ( (0, 1) ,(_,_)) @sfr/7 

> {chastart J chastart) 

and where ~ ( (0, 1) , (_, _) ) @strp abbreviates: 

{{0,0), {.,.)) @strp V {{1,0), {.,.)) @strp V {{1,1) ,{.,.)) @strp. 

Finally, the complete behavior of the Basic Stopwatch is formalized by: 

^^^iasic ■~ tfansfi ; {transf2 A transfi) 

Basic Stopwatch with Reset 

We now enhance the behavior of the Basic Stopwatch by including the RESET button. Every time RESET 
is pressed, the Stopwatch re-initializes and starts executing from the beginning, i.e. from chajnit- This 
modal behaviour is illustrated by the Cha'^Lo diagram in Figure IHiii) where the dotted box is a copy 
of Figure |2l;ii), depicting the hierarchical mode c/ia^^,^,-^. The preemptive transitions, outside the box, 
have higher priority than the transitions inside the box. That is, pressing RESET has higher priority than 
pressing STRP. Every time RESET is pressed, the mode cha^t is re-executed. Formally: 
chai,,, := {{{_,_), {0,1)), {{.,.), {.,.)))@reset ^ 

{chal^sic ' chal^sic) ® {{{-,-), (-, mit) ),((_,_), (_, _) ) ) @mode 

Findings 

To conclude the Stopwatch case study, note that Separation Logic was not originally intended to express 
the modal behavior of a system, such as that of the Stopwatch. The above specifications seem to sug- 
gest, however, that Separation Logic may come in handy in at least two unexpected ways. First, the 
presented textual specifications denote the meaning of the graphical diagrams in Figure I2ii) and (iii). 
These diagrams can be made (i.e. specified) by means of a graphical user interface. The correspond- 
ing graphical-specification process, in turn, could be a complementary (or competitive) alternative for 
the textual-based Esterel specification process. Second, since the presented logics elegantly capture 
modal behavior, they can of course also be used to provide an alternative formal semantics of languages 
such as Esterel [31. 
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Figure 3: (i) The 2x2 Switch, (ii) a full FIFO buffer, and (iii) an empty FIFO buffer. 

4 Switch 

Our third case study is a 2 x 2 Switch. Its shared-memory behavior was originall>|f] specified in the 
guarded-command language Blue spec [2]. In this section, however, we introduce the Logic of Hierar- 
chical Snapshots and reuse ChaLo (cf. Table [T]) to specify the Switch's behavior. 

This section consists of three parts. First, we present the design intent of the Switch in Section 14.11 
Second, we introduce the Logic of Hierarchical Snapshots in Section l42l Finally, we partially specify 
the Switch's behavior in Section 1431 

4.1 Design Intent 

The 2x2 Switch in Figure[3ti) contains two input FIFOs (iO and il) and two output FIFOs (oO and ol). 
A data packet can arrive on iO or il. If the first bit of that packet has the value 0, then it is routed to 
oO, else to ol. Each FIFO has the capacity to store 1021 data packets and 3 management packets (see 
below). Each packet contains 32 bits. A data packet can only move if the output FIFO is not full. A 
shared resource collision can occur when the data packets at the head of both input FIFOs have the same 
destination buffer (i.e. shared memory). In this case, iO is given priority and il's data packet is delayed. 

The three management packets (of each FIFO) are the head and tail pointers and the empty entry 
in Figure IHii). The head pointer refers to the entry in the FIFO that contains the head data packet (if 
any). The tail pointer refers to the first empty entry. To distinguish a full FIFO from an empty FIFO 
(cf. Figure |3liii)), one buffer entry is not used to store a data packet. This entry, hence, stores the third 
management packet of the FIFO. We also mention that the head and tail pointers are stored in buffer 
entries 1022 and 1023, respectively. 

4.2 Logic of Hierarchical Snapshots 

The Logic of Snapshots has the purpose to concisely describe hierarchical storage. We present examples 
below, omitting the obvious but lengthy formal definitions. 

Suppose input buffer iO is assigned to photographer Phi. Then Phi can zoom in on, say, entry 
number 3 of iO and take a snapshot of the stored packet pack. If pack resembles the number five, then 
Phi observes 5@/0.3. Phi can zoom in further by taking a snapshot of, say, the first two bits of pack. 
Phi would then observe: l@/0.3.0 * 0@/0.3.1. The first conjunct expresses that the very first bit (index 
0) has the value one. The second conjunct states that the second bit (index 1) has the value zero. This 
indeed corresponds to the bit notation of the number 5, which is 0. . .0101 with the least significant bit 



■'if the reader is unfamiliar with Bluespec, he or she can also think of TLA+ 1111 as an alternative specification language 
for the 2 X 2 Switch. 
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Figure 4: Three semantic snapshots. 

(index 0) being the rightmost bit. If Phi chooses to observe d = 10 consecutive bits of pack, starting from 
bit index n = I, then we may write 2@/0.3.1 — 10 because these ten bits, 0. . .010, resemble the number 
two. The general notation is: v@i0.3.n—n' with n' := n + d — I, and where v is the con^esponding value. 
Finally, note that Phi can also combine disjoint snapshots of iO as for example: 
l@/0.3.0 * 0@/0.3.1 * 29@/0.8 * 9@/0.12.4-17. 



The Semantics of Hierarchical Snapshots 

Snshot, the domain of semantic snapshots for the 2x2 Switch, is defined in terms of Tree, a parameterized 
semantic algebra: shot e Snshot := Tree [A, 1024, ^il] 

The first parameter refers to the 4 buffers in Figure [3li). Each buffer contains 1024 entries of 32 bits 
each. 

Instead of giving a lengthy definition of Tree, we illustrate three semantic snapshots in Figure HI For 
example, shot2 is the semantic snapshot that models the syntactic snapshot l@o0.9.5. 

Some more concepts follow. A path is a concatenation of edge numbers, such as o0.9.5. The trace 
of a tree shot is the set of paths that characterize all the level 3 nodes (i.e. bits) of shot. E.g.: 

Trace{shoti) = {/O.O.O, /O.O.I, ... ,j0.0.31} 

Trace (shotz) = {o0.9.5} 
Two trees are disjoint ((j) iff their traces are disjoint: 

shota '^shoth iff Trace (shota) H Trace{shoth) = 
Thus, shot\ tJ shot2 holds. Since shot\ and shotz are disjoint, they can be combined (.) into shotj, as 
follows: 

shotT, = shot\ . shot2 with 
Trace (shot^ ) = Trace (shot i)U Trace {shot2 ) 
Indeed, shotT, in Figure |4]represents the combination of shot\ and shot2. It captures the contents of entry 
number of buffer iO and bit number 5 of entry number 9 of buffer oO. Finally, when two non disjoint 
trees are combined, then ± is returned. E.g.: shot\ . shot\ = ±. 

4.3 Some Specifications 

In conformance to the hierarchical snapshots, presented in the previous section, we now present ChaLo 
specifications of the Switch. 

As a first example, we want idleInputBuf[buf] to state that no packet is taken out of input buffer buf 
-where buf is /O or /I. In accordance to Figure [3tii-iii), we therefore want to specify that buf?, head 
pointer head does not change. Since head is stored in buf .first, we write the following where buf is /O 
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or /I: 

(i) idleInputBuf[buf] =3head. {head, head) @buf. first 

As a second example, we want retrieveFromBuf[buf] [«i][«2] [value], with buf equal to /O or i\, to 
state that: value value corresponds to value@buf.head .ni — n2 where head is the head pointer of buf. 
That is, we want to retrieve (but not extract) the n2 — ni + \ bits, starting from index n\ , from the head 
data packet in buf. Formally, we have: 

(ii) retrieveFromBuf[buf] [«i][«2] \value\ 

(iii) = 3 head. ( {head, S) @ buf. first 

(iv) * {value, -)@buf.head.ni—n2 ) 

Note that (iii) does not specify the new contents of buf. first and (iv) does not specify the new contents of 
buf.head.ni —n2. 

Based on (ii), we can now define the following: 
(v) retrieveFromBuf[buf] [value] = retrieveFromBuf[buf] [0][31] [value] 

where buf is iO or il. That is, value represents the complete data packet that is stored at the head of buf. 

As a third example, we want extractFromBuf[buf] [«i][«2] [value], with buf equal to iO or il, to be 
similar to retrieveFromBuf[buf] [^2] [value], except that we now not only retrieve but also extract the 
data bits from the head packet in buf. Formally: 

(vi) extractFromBuf[buf] [ni][n2\ [value] 

(vii) = 3head. { {head, {I + head) mod 1022) @ buf .first 

(viii) * {value, -)@ buf. head. ni—n2 ) 
Note that in (vii) we now do specify the new contents of buf. first. 

Based on (vi), we can define the following where buf is iO or il: 
(ix) extractFromBuf[buf] [value] = extractFromBuf[buf] [0][31] [value] 
An additional remark is that, constraints, such as: 

(x) 3x.extractFromBuf[buf][x\ notEmptyBuf[buf] 

also have to be specified. In words, (x) states that extracting a packet x from buffer buf implies that buf 
is not empty. The trivial definition of notEmptyBuf is omitted. 
As a fourth example, consider: 

(xi) {depart ■.x,0)@iO = extractFromBuf[iO][0][3l][x] 

(g) extractFromBuf[iO] [0] [0] [0] 
It states that iO's head packet x is extracted from the buffer and that it's first bit has the value 0. Similarly: 

(xii) {arrive ■.y,0)@oO = insertInBuf[oO][0][3l][y] 

(g) insert InBuf[oO][0][0][0] 
The definition of insert InBuf is omitted from this paper. 
Based on the above, we now define: 

(xiii) 3z. { {depart : z,0) @iO {arrive : z,0) @oO ) 

This expresses, amongst other things, that the departed packet x and the arrived packet y are one and the 
same packet z.. Finally, consider: 

(xiv) 3z. { {arrive : z,0) @oO {depart : z,0) @iO V {depart : z,0) @il ) 

The arrival of a packet at oO implies its departure from iO or il. Continuing in this manner, we can 
completely capture the Switch's behavior. 

Findings 

To conclude the 2x2 Switch case study, note that Separation Logic is typically used to verify pointer- 
intensive code |[T3l [T5l . Since the Switch also contains pointers, it is less surprising, compared to the 
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Stopwatch case study, that Separation Logic can be used as a specification language for shared-memory 
systems such as the Switch. 

5 Conclusions & Future Work 

We have captured the concurrent behavior of three very different systems by means of Separation Logic 
and its natural extensions. Instead of specifying a modal-based system in Esterel and a shared-memory 
system in Bluespec, we are now able to specify both systems by means of the same formalism -not to 
mention the Subway system which was originally specified in LUSTRE. That is, we have a unifying 
framework for multiple design approaches that initially seemed disparate. Alternatively, we could (in 
future work) provide a semantics for LUSTRE, Esterel, and Bluespec in our unifying formalism. 

Critics may remark that any other specification language, say Esterel, can also be used to capture 
the behavior of any of the three presented systems. Hence, they might question the relevance of the 
formalism, presented in this paper. We respond in the two following ways. 

First, we have provided insight into how three seemingly independent concurrent systems are related 
to each other: (i) the Switch's behavior merely differs from the Subway's behavior in that it requires 
hierarchical snapshots instead of plain snapshots, and (ii) the Stopwatch's behavior merely differs from 
the Subway's in that it requires change of change (and change of change of change) to be specified instead 
of only change. Now, in our formalism, anything that can be expressed with plain snapshots can also be 
expressed with hierarchical snapshots. Similarly, anything that can be expressed with change (cf. ChaLo) 
can also be expressed with the more powerful concept of change of change (cf. Cha^Lo), etc. So, all 
three concurrent systems, presented in this paper, can be expressed in one and the same formalism which 
we denote here (for the first time) by: ChafLo, which is an instantiation of ChaJJLo. The parameters n 
and h denote the number of changes and the hierarchical depth, respectively. For example, n = h = I for 
the Subway, n = 4 and /j = 1 for the Basic Stopwatch with Reset, and n = I and /j = 3 for the Switch. 

The potential power of our formalism ChaJjLo lies in being able to select a specific subset, 
defined by the values of n and h, for a given application domain. 

Second, we invite the reader to check whether the other specification languages (e.g. Esterel) can in 
fact capture the behavior of all three concurrent systems in a uniform and sufficiently concise way. As 
mentioned in the introduction, practitioners will typically not use Esterel to specify a shared-memory 
system and will not use Bluespec to specify the modal behavior of e.g. a Stopwatch. 

Finally, in line with this paper, we also refer to our complementary work [51 in which we have 
applied different specification languages (including Bluespec) to one and the same case study (i.e. the 
2x2 Switch case study). 
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